%% Based on a TeXnicCenter-Template by Gyorgy SZEIDL.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%----------------------------------------------------------
%
\documentclass{book}%
%
%----------------------------------------------------------
% This is a sample document for the standard LaTeX Book Class
% Class options
%       --  Body text point size:
%                        10pt (default), 11pt, 12pt
%       --  Paper size:  letterpaper (8.5x11 inch, default)
%                        a4paper, a5paper, b5paper,
%                        legalpaper, executivepaper
%       --  Orientation (portrait is the default):
%                        landscape
%       --  Printside:   oneside, twoside (default)
%       --  Quality:     final(default), draft
%       --  Title page:  titlepage, notitlepage
%       --  Columns:     onecolumn (default), twocolumn
%       --  Start chapter on left:
%                        openright(no, default), openany
%       --  Equation numbering (equation numbers on right is the default):
%                        leqno
%       --  Displayed equations (centered is the default):
%                        fleqn (flush left)
%       --  Open bibliography style (closed bibliography is the default):
%                        openbib
% For instance the command
%          \documentclass[a4paper,12pt,reqno]{book}
% ensures that the paper size is a4, fonts are typeset at the size 12p
% and the equation numbers are on the right side.
%
%----------------------------------------------------------
\usepackage{hyperref}

\begin{document}

\frontmatter
\title{Redick Grows \\ How I Used SableCC and Stepwise Refinement to Build Redick: A Phased Guide}
\author{Terrence Monroe Brannon}
\maketitle
\tableofcontents

\chapter{Introduction}

Redick is an open-source Java implementation of \href{http://www.JSoftware.com}{the J Programming Language}. I wanted to learn Java and I wanted an implementation of J that was open source and fixed the minor \href{http://code.google.com/p/redick/wiki/ChangesFromJ}{weaknesses I saw in the language}. I am writing this guide because I think it will help someone who wants to learn SableCC and implement an interpreter. I started writing it at a certain phase of development. I had read the SableCC intro material and managed to parse a simple Redick expression and print out its component parts. From here, I began to wonder how to execute the expression. I figured I needed a scaleable infrastructure for this. I felt that Scheme was somewhat J-like and certainly quite Redick-like, so I googled for Java Scheme and up came an old version of Peter Norvig's JScheme. I'm glad he kept his old, naive, inefficient version around. It was well-documented and very obvious in what it does. The more recent versions of JScheme are very advanced and very large in codebase - not the sort of thing to get your feet wet with.

So after understanding version 1.4 of JScheme, I decided to write this guide to chronicle the major steps of Redick development for the benefit of others.

\mainmatter

\chapter{Creating a Redick expression parser}

If you get version 28 of Redick from \href{http://code.google.com/p/redick/source}{the repo}, you will have something that is very similar to the postfix parser exemplified in Chapter 3 of Dr. Gagnon's thesis. The difference is that it parses the Redick prefix syntax instead.

If you compile Compiler.java and then enter 
\begin{verbatim}
(+ 12 14)
\end{verbatim}
and then hit control-z enter, you should see the parse of the expression into component parts.

Now, it was at this point, that I went off and studied the architecture of Norvig's JScheme. I came back all ready to spend time coding an Environment class and a Primitive class and then installing all sorts of primitives. But I realized that all of this was a form of premature planning. It is more important to keep making things work, even if they are not properly architected. You can always refactor later. Always keep making something that does a little more than you had earlier and save yourself the agony of grandiose plans which may never yield fruit.

So, instead of all of that coding of classes for the interpreter, I set myself the simple task of adding my two numbers. Now... I already knew about the \verb+getNode()+ style methods, but I was not sure how to actually convert the node element into actual numbers and add them. So that became my next simple concrete step and the motivation for this article.

At first, I wanted to run to the mailing list and ask, but I decided against it. With a little surfing about in my Eclipse IDE, I was able to discover that my the get methods were returning nodes which had toString methods. And from there, googling ``Java convert string double'' had me home free.

So, if you get revision 29 of the repo, you can again compile Compiler.java and run, but this time, you get a parse and the sum. Not bad for a night's work.

Alright, the next morning I was ready to separate things out a bit. Again, as tempting as it was to build out into an Environment and Primitive class, my Java is just not strong enough to write a bunch of stuff and then string it together later... this is about baby steps. And another such step we shall take.

What I need is a lookup from a string representing a Redick operator/verb/function/call-it-what-you-want to an object which will apply itself to some arguments.... hmmm, let us reflect. Again, I'm reaching. I'm thinking of classes for everything. No, it's time for a humbling if-then statement. Well, the if-then business did not work out. Instead, what I did was leverage the fact that I had a method available for each verb. So, revision 32 has a Translation class that will add, subtract, multiply and divide. Also, at this point  I got a ton of help on comp.lang.java.programmer regarding how to improve this code \cite{cljp:tighten}.

\subsection{Looking 



\backmatter

\chapter{Afterword}

The back matter often includes one or more of an index, an afterword,
acknowledgements, a bibliography, a colophon, or any other similar item. In
the back matter, chapters do not produce a chapter number, but they are
entered in the table of contents. If you are not using anything in the back
matter, you can delete the back matter TeX field and everything that follows it.
\end{document}
